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(54) Title: DISTRIBUTION OF A SERVICE REQUEST 
(57) Abstract 

The present invention relates to a system and 
a procedure for distribution of a service request in a 
computer system based on a client-server architecture 
and comprising at least one client (1), which sends 

service requests to servers (2', 2^ 2"); one or 

more servers (2', 2^, 2"), which provide callable 
services for the client (1); and middleware means 
(3). According to the invention, the system comprises 
a multiplexing server (4), by means of which the 
client's (1) service request is copied and distributed 
to the servers (2\ 2^, 2") for parallel execution; 
a queue system (5', 5^, 5") for storing service 
requests not yet executed; and queue handling means 
(6*, 6^, 6"), by means of which the service 
requests placed in the queue system (5^ 5^, 
5") are passed on for re-execution. The invention 
allows transparent distribution of the service request, 
guarantees improved reliability of operation in failure 
situations and consistency of resources. 
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DISTRIBUTION OF A SERVICE REQUEST 

BACKGROUND OF THE INVENTION 

The present invention relates to a system as 
5 defined in the preamble of claim 1 for distribution of 
a service request in a computer system based on a cli- 
ent-se2rver architecture and to a procedure as defined 
in the preamble of claim 8 for distribution of a serv- 
ice request in a computer system based on a client - 

10 server architecture. 

In a three-level client-server architecture, 
the server/ servers produces /produce services requested 
by the client/clients. An agent acting between these 
is middleware, which is used to take care of e.g. the 

15 routing of service requests to the appropriate server, 
equalisation of load and management of transactions. 

A typical area of application is telecommuni- 
cation network management. In this case, the client 
application is e.g. a customer management system and 

20 the server application represents e.g. an SCP intelli- 
gent network component (Service Control Point, SCP) . 
When the operation of the SCP intelligent network com- 
ponent, i.e. the node to be managed, is to be rendered 
as reliable as possible, the node is physically dou- 

25 bled, so that both nodes contain the same service 
data. The duplication must not be visible to the cli- 
ent process, but changes made by the client in the 
service data must be copied to both nodes . In other 
words, when the client sends a management data update 

30 request, the update request must be transmitted to all 
the servers and the management data must be updated in 
all the nodes to be managed, but the client must per- 
ceive the entire transaction as if it were only deal- 
ing with a single server/node. 

35 In prior-art systems, a service request can 

be distributed in a client application separately to 
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each identical resource. Thus, the distribution archi- 
tecture is visible to the client application. Further, 
if an update operation in one of the nodes to be man- 
aged is unsuccessful e.g. due to a telecommunication 
5 problem, the result is that the nodes are in a non- 
consistent state because the update cannot be can- 
celled automatically from the middleware level. 

In middleware environments, a two-stage com- 
mitment procedure is previously known. In such a pro- 

10 cedure, the changes caused by a service request are 
first saved temporarily, whereupon a transaction moni- 
tor sends a preliminary commitment command (pre- 
commit) to each server. If the transaction monitor re- 
ceives a confirmation from each server, then it sends 

15 the servers an actual commitment command (commit) , and 
the changes caused by the service request are updated 
simultaneously. If no confirmation is received from 
one of the servers, then no commitment command is sent 
and the changes are not updated, thus preserving the 

20 consistency of resources. 

Two-stage commitment is in itself a workable 
procedure. The problem is that not all of the nodes to 
be managed are capable of it. In other words, a serv- 
ice request can only be cancelled if the cancellation 

25 decision is made from the client application. As a re- 
sult, however, the distribution is visible to the cli- 
ent . 

SUMMARY OF THE INVENTION 

30 The object of the present invention is to 

disclose a new type of procedure and system for elimi- 
nating the above-mentioned drawbacks. 

A specific object of the present invention is 
to disclose a solution for achieving transparent dis- 

3 5 tribution of a service request and consistency of re- 
sources . 



wo 99/57620 



3 



PCT/FI99/00374 



As for the features characteristic of the 
present invention, reference is made to the claims. 

The system of the invention for distribution 
of a service request in a computer system based on a 
5 client-server architecture comprises at least one cli- 
ent application/client process which sends service re- 
quests to servers; one or more server applica- 
tions/server processes providing services which can be 
called by the client; and middleware means; further- 

10 more, the system comprises a multiplexing server, a 
queue system and queue handling means, which are im- 
plemented e.g. as software components. For each 
server, preferably a separate queue system and queue 
handling means are provided. This ensures maximal re- 

15 liability in failure situations. The multiplexing 
server provides the same service interface as the ac- 
tual servers, and the names, of the services of the ac- 
tual servers are changed, causing the clients' service 
calls to be directed to the multiplexing server. 

2 0 According to the invention, by means of the 

multiplexing server, the client's service request is 
copied and distributed to the servers for execution. 
By means of the multiplexing server, responses are ob- 
tained from the servers and a single response for the 
25 calling client is composed from them. If any one of 
the servers returns a successful response, then a suc- 
cessful response is returned to the client. Thus, the 
duplication is hidden from the client. For those serv- 
ers which return an unsuccessful response due e.g. to 

3 0 a telecommunication failure preventing communication 

with the resource to be managed, the service request 
is placed in the queue system for the server in ques- 
tion. The multiplexing server does not take care of 
service requests placed in a queue system but is ready 
35 to serve subsequent service requests of the cli- 
ent/clients. 
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Further, according to the invention, service 
requests not fulfilled are stored in server-specific 
queue systems, which comprise a separate gueue for 
each service provided by the server. The queues are 
based on prioritisation of requests, i.e. a service 
request entered in a queue with the highest priority 
xs the first one to be served and removed from the 
queue. The queue system is implemented e.g. in the 
form of a file. 

Further, according to the invention, the 
queue handling means are used to pass on the service 
requests placed in the queue system to the servers at 
predetermined time intervals for re-execution For ex 
an^ple, a list of the queues to be monitored is main- 
tained. A service request is taken from the queue, and 
the server service corresponding to the queue is 
called. 

As compared with prior art, the present in- 
vention has the advantage that it allows transparent 
distribution of a service request, in other words, a 
client's service request can be copied to a plurality 
of servers without the copying being visible to the 
client. Furthermore, according to the invention, in- 
stead of cancellation of a transaction, a queue mecha- 
nism IS used whereby attempts to execute the transac- 
tion are repeated until the fault has been corrected 
and the transaction is successfully carried out or un- 
til a time limit is exceeded. This makes it possible 
to achieve a greater reliability in failure situations 
than before. Moreover, the invention requires only 
minimal changes in the existing middleware architec- 
ture as regards the client and server processes, so it 
can be easily implemented and taken into use. 

In an embodiment of the invention, the multi- 
plexing server, the queue system and the queue han- 
dling means are logically disposed in conjunction with 
the existing middleware means between the client and 
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the servers. Each server communicates with a given 
telecommunication network component, which network 
components are managed by a management application 
communicating with the client. The servers provide 
5 identical services to the client, with the difference 
that different servers communicate with different 
manifestations of the network components to be man- 
aged . 

In an embodiment of the invention, a table of 

10 the servers to which the service request is to be du- 
plicated is maintained in the multiplexing server. The 
services of the servers in the table are preferably 
called asynchronically by the multiplexing server, in 
other words, having transmitted a service request to 

15 one server, the multiplexing server starts transmit- 
ting the service request to the next server without 
waiting for a response from the first server. This al- 
lows parallel execution without delays. 

In an embodiment of the invention, before 

20 calling a service, a check is carried out on each 
server by the multiplexing server to determine whether 
there are already any service requests in the queues 
corresponding to the service in question. If the queue 
concerned already contains service requests, then the 

25 new service request is placed directly in the appro- 
. priate queue and assigned the lowest priority at the 
moment , 

In an embodiment of the invention, a cycle 
counter and/or a time stamp are/is attached to service 

30 requests transferred into a queue system to allow con- 
trol of the length of time each service request is re- 
tained in the queue system. 

In an embodiment of the invention, to re- 
trieve a service request from a queue by using queue 

35 handling means, the server service corresponding to 
the queue is called synchronically , in other words, a 
response to the call is awaited. If a message indicat- 
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ing successful execution of the service request is re- 
ceived from the server, then the service request has 
been successfully executed. If the server is still un- 
able to execute the service request, then the service 
5 request is again placed in the queue and the cycle 
counter for the service is incremented. However, if 
the time stamp and/or cycle counter of the service re- 
quest exceed certain predetermined values, then the 
service request is deleted from the queue and the 
10 situation is logged. 

In an embodiment of the invention, the mid- 
dleware means consist of Tuxedo middleware. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 In the following, the invention will be de- 

scribed by the aid of a few examples of its embodi- 
ments by referring to the attached drawing, wherein 

Fig. 1 presents an embodiment of the system 
of the invention, and 

20 Fig- 2 presents a functional diagram of a 

system according to the invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

Fig. 1 presents an embodiment of the system 
25 of the invention for implementing telecommunication 
network management in which a management application 8 
is used to manage components 7\ 7% 7^ of the telecommu- 
nication network- In this example, the network compo- 
nents are SCP nodes in an intelligent network, nodes 7^ 
30 and 7^ being backup copies of node 7\ Nodes 7^ and 7^ 
thus contain the same intelligent network service data 
as node 7^. A notable feature is that the SCP nodes 
7^,7^,7^ are incapable of two-stage commitment to data 
updates. A management application 8 communicates with 
35 a client process 1, and the SCP nodes 7\7^,7^ communi- 
cate with server processes 2^,2^,2^. Functioning be- 
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tween the client process 1 and the server processes 
2^2^,2^ is Tuxedo middleware application management 
software 3, which takes care of e.g. routing of the 
service requests to the appropriate server, load 
5 equalisation and transaction management. Implemented 
as logical software components disposed between the 
client process 1 and the server processes 2\2^,2^ are 
a multiplexing server 4, queue handling means 6^,6^,6^ 
and queue systems 5^, 5% 5^. For each server, there is 

10 one queue handling means and one queue system. 

Fig. 2 presents a functional diagram of a 
system according to the invention in a Tuxedo environ- 
ment. By means of a client application (not shown), a 
call for service y is issued, which service is actu- 

15 ally implemented as service y' in server A 2^ and 
server B 2^. First, configuration information is read 
from a run-time management information base (MIB) in 
Tuxedo 3. The configuration information comprises e.g. 
server groups, routing data for the groups, queue pa- 

2 0 rameters and queue space data. When the service re- 

quest y is received by the multiplexing server 4, a 
check is carried out to establish whether the queue 
systems 5^ and 5^ (not shown) for servers 2^ and 2^ al- 
ready contain any messages. In this way, the order of 

25 the service requests is maintained. The name of the 
service is changed to y' . A routing field is added to 
the message. 

Next, a call for service y' is sent asyn- 
chronically to each application server 2^ and 2^. Be- 

30 fore the call, the routing field is assigned a value 
which is obtained from a table maintained by the mul- 
tiplexing server 4, said table containing routing 
field values for the se2rvers 2^ and 2^. The values were 
obtained from the Tuxedo 3 configuration information 

3 5 when the multiplexing server 4 was started up. Thus, 

the service requests are routed to different applica- 
tion servers. Next, responses are obtained from the 
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application servers 2^ and 2^ it is to be noted that 
Tuxedo automatically collects the responses to asyn- 
chronous calls. The title part of the message is 
checked for errors, and the results are added to a re- 
sults table which contains table locations for each 
application server 2> and 2^ Based on the results ta- 
ble, a response message for the client application is 
composed. 

The results table is analysed. If errors are 
detected e.g. in the response of application server 2\ 
then a time stamp and a cycle counter are attached to 
the message concerned. Further, the lowest priority in 
the queue system 5^ corresponding to the application 
server 2^ is found out and the message is assigned the 
next priority level below it. After this, the message 
is placed in the queue system 5^ for the application 



server 2 



The queues are polled using the queue han- 
dling means 6^ and 6^ (not shown) . For each service, 
there are specified queues in the queue systems 5^ and 
5'. For each application server 2\ 2=^ there is one 
queue system 5\ 5^ and one set of queue handling means 
&\ B\ Using queue handling means 6\ a call for serv- 
ice y is issued synchronously. Before the call, the 
time stamp and cycle counter are checked. If the time 
stamp is too old and the cycle counter has a suffi- 
cient value, then the message is deleted from the 
queue system 5\ and the situation is logged. If an er- 
roneous response is still obtained from the applica- 
tion server 2\ then the message is placed back into 
the queue and the cycle counter value for the message 
is incremented. 

The invention is not restricted to the exam- 
ples of its embodiments described above, but instead 
many variations are possible within the scope of the 
inventive idea defined in the claims. 
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CLAIMS 

1. System for distribution of a service re- 
quest in a data system based on a client -server archi- 
tecture and comprising at least one client (1) , which 

5 sends service requests to servers (2^,2^, . ,2") ; one 
or more servers (2^, 2\ . . . , 2^") , which provide callable 
services for the client (1); and middleware means (3), 
characterised in that the system comprises 

- a multiplexing server (4) , by means of which 
10 the client's (1) service request is copied and dis- 
tributed to the servers (2\ 2^, . . . , 2"") for parallel 
execution, the client (1) is notified of success- 
ful/unsuccessful execution of the service request, and 
if one of the servers (2^, 2^, . . . , 2") is unable to exe- 

15 cute the service request, then the service request is 
transferred into the queue system (5^ , 5^ , . . . , 5") for 
the server concerned; 

- a queue system (SS 5^, . . . , 5^) for each server 
(2\ 2^, . • . , 2") for storing service requests not yet 

2 0 executed ; and 

- queue handling means (6^ 6^ , . . . , 6"") for each 
server (2^,2^, . . . , 2") , said means being used to pass on 
service requests placed in the queue system 
(SS 5^, . . , , 5") for re-execution at certain time inter- 

25 vals. 

2. System as defined in claim 1, charac- 
terised in that 

- the multiplexing server (4) , the queue system 
(51, 52 , . . - , 5n) and the queue handling means 

30 (61, 62 , . . . , 6n) are disposed in conjunction with the 
middleware means (3) between the client (1) and the 
servers (21,22, . . . ,2n) ; 

- each server (21 , 22 , . . , , 2n) is connected to a 
telecommunication network component (71, 72, . , . , 7n) , 

35 which network components (71,72, .. . , 7n) are managed 
using a management application (8) communicating with 
the client (1) ; and 
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- the servers (21 , 22 , . . , , 2n) provide identical 
services for the client (1) . 

3 . System as defined in claim 1 or 2 , 
characterised in that 
5 - a table of the servers (2^ 2^ , . . , , 2") to which 

the service request is to be copied is maintained in 
the multiplexing server (4) ; and 

- the services of the servers (2^, 2^, . . . , 2") are 
called asynchronically by the multiplexing server (4) . 

10 4. System as defined in any one of the pre- 

ceding claims 1 - 3, characterised in that 

- before issuing a call for a service, a check is 
carried out on each server by the multiplexing server 
(4) to determine whether there are any service re- 

15 quests in the queue systems (5^5^, . . . , 5") ; and 

- if there are already service requests in the 
queue system (5\ 5^, . . . , B'') , then the service request 
is placed in the queue system (5^ 5^, , . . , 5") by the 
multiplexing server (4) and assigned the lowest prior- 

2 0 ity at the moment. 

5. System as defined in any one of the pre- 
ceding claims 1 - 4, characterised in that a 
cycle counter and/or a time stamp are/is attached to 
the service requests transferred into a queue system 

25 (5^,5^, . . . , 5") by the multiplexing server (4) . 

6, System as defined in any one of the pre- 
ceding claims 1 - 5, characterised in that 

- using the queue handling means (6^, 6% . . . , 6") , 
the services of the server (2^ , 2^ , . . . , 2") are called 

3 0 synchronical ly ; 

- if the server (2^, 2% . . . , 2") is unable to carry 
out the service, then the service request is returned 
to the queue system (5\ 5^ , . . . , 5") by the queue han- 
dling means (6^ 6^, , . . , 6") and the cycle counter for 

3 5 the service request is incremented; and 

- if the time stamp and/or cycle counter of the 
service request exceed certain predetermined values. 
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then the service request is deleted by the queue han- 
dling means (6^ • • - / 6") . 

7. System as defined in any one of claims 1 - 
6, characterised in that the middleware means 

5 (3) consist of Tuxedo middleware. 

8. Procedure for distribution of a service 
request in a data system based on a client -server ar- 
chitecture and comprising at least one client (1) ; one 
or more servers (2\2^, . , . , 2"") ; and middleware means 

10 (3) , in which procedure service requests are sent from 
the client (1) to the servers (2^2^, . . . ,2") , and serv- 
ices called are provided for the clients (1) by the 
servers (2^, 2% . , . , 2"") , characterised in that 

- by means of a multiplexing server (4) , the cli- 
15 ent ' s (1) service request is copied and distributed to 

the servers (2^, 2^ , . . . , 2") for parallel execution, the 
client (1) is informed about successful/unsuccessful 
execution of the service request, and if one of the 
servers (2^, 2^, . . , , 2"") is unable to carry out the serv- 
20 ice request, then the service request is transferred 
into a queue system (5^, 5^, . . . , 5") for the server con- 
cerned; 

- service requests not yet executed are stored in 
server-specific queue systems (5^,5^, . . . , 5*^) ; and 

25 - using server- specif ic queue handling means 

(6^, 6^, . . . , 6") , service requests placed in the queue 
system (5^5%..., 5") are passed on for re-execution at 
certain time intervals. 

9. Procedure as defined in claim 9, char- 
30 acterised in that 

- the multiplexing server (4) , the queue system 
(5\5%...,5") and the queue handling means (6) are 
disposed in conjunction with the middleware means (3) 
between the client (1) and the servers (2\ 2% . . . , 2") ; 

35 - each server (2^ , 2% . . . , 2") is connected to a 

telecommunication network component (7\ 7^ . . . , 7") , 
which network components (7\7%...,7") are managed by 
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a management application (8) communicating with the 
client (1) ; and 

- identical services are provided for the client 
(1) by the servers (2\ 2^ . . . , 2°) . 

10. Procedure as defined in claim 8 or 9, 
characterised in that 

- a table of the servers (2S2%...,2") to which 
the service request is to be copied is maintained in 
the multiplexing server (4); and 

- the services of the servers (2S2%...,2") are 
called asynchronically by the multiplexing server (4). 

11. Procedure as defined in any one of the 
preceding claims 8-10, characterised in that 

- before issuing a call for a service, a check is 
carried out on each server by the multiplexing server 
(4) to determine whether there are any service re- 
quests in the queue systems (5^ 5^ . . . , 5") and 

- if there are already service requests in the 

queue system (5\ 5^ 5"), then the service request 

is placed in the queue system (5', 5', . . . , 5") by the 
multiplexing server (4) and assigned the lowest prior- 
ity at the moment. 

12. Procedure as defined in any one of the 
preceding claims 8-11, characterised in that 
a cycle counter and/or a time stamp are/is attached to 
service requests transferred into a queue system 
(5 ,5 , ... ,5") by the multiplexing server (4) . 

13. Procedure as defined in any one of the 
preceding claims 8-12, characterised in that 

- using the queue handling means (6\6\...,6") 

the services of the server (2S2^ 2") are called 

synchroni cal ly ; 

- if the server {2\ 2\ . . . , 2") is unable to carry 
out the service, then the service request is returned 

35 to the queue system {5\s' 5") by the queue han- 
dling means {6\ 6' ,6") and the cycle counter for 

the service request is incremented; and 
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- if the time stamp and/or cycle counter of the 
service request exceed certain predetermined values, 
then the seinrice request is deleted by the queue han- 
dling means (6S 6^, , . , , S"") . 

14 . Procedure as defined in any one of the 
preceding claims 8 - 13, characterised in that 
the middleware means (3) consist of Tuxedo middleware. 
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